Mobile communication devices, including smartphones, include usually audio outputs and vibrator outputs in order to output signals to the user. Applications of these signals include alerting the user of an incoming call or any other events, gaming or other applications, etc.
As depicted on FIG. 1, these outputting means comprise physical parts like a loudspeaker LS or a vibrator apparatus VB, and hardware circuits controlling the physical parts and preparing, coding, decoding and adapting the signals for them, like amplifiers Amp1, Amp2, multiplexers Mux1, Mux2, vibrator controllers VC1, VC2 or Digital-to-Analog Converter DAC. They are referred to as “Audio CODEC” (AC).
All these circuits constitutes resources that are made available to the applications running on the mobile communication devices through software drivers SD implemented within the kernel of the operating system embedded in the devices.
These drivers allow access to the audio and vibrator resources for the applications by providing standardized interfaces, or API (Application Programming Interfaces). The aim is that the applications can access to the resource thanks to known software functions without knowing about the actual underlying technology (type of amplifiers, loudspeaker or vibrator's furnisher or model, etc.), so that the same application can be run on different mobile communication devices without modification providing the operating system is the same (e.g., iOS, Android, Linux, Microsoft Windows, etc.).
Most of the operating systems (OS) allow several applications to be running concurrently or at least on time-sharing mode. This implies that the audio and vibrator resources may be requested by two or more applications.
To avoid that a same resource (the vibrator or a loudspeaker) is used by more than one application at a time, the system should properly handle concurrent accesses to the resource.
The state-of-the-art solutions consist in controlling the concurrent accesses at the software driver, like depicted in FIGS. 2a and 2b. Software drivers are provided at the layer of the OS (Operating System) kernel which sits between the hardware layer (that comprises the Codec AC and the vibrator VB and loudspeaker LS) and the user space wherein run the applications App1, App2 and services VS.
These solutions lie in having a single point of control, which is provided by the audio driver AD. The audio driver AD is in charge of any signals transmitted to or from the audio Codec AC (and therefore the resources LS, VB, with which it is associated).
FIG. 2a represents a first solution where a vibrator software driver VD is provided in addition to the audio software driver AD. An application App1, App2 willing to use the vibrator makes typically a call to a vibrator service VS provided within the user space (which can be embedded in the application itself, or available as plug-in or other independent modules). The vibrator service VS then makes a standardized call to the vibrator driver VD.
The vibrator driver VD should route the call to the audio driver AD in order to let it control the concurrent accesses to the hardware.
Such a solution requires a dependency between the vibrator driver VD and the audio driver AD. Such a dependency is not desirable as it makes it more complex to develop drivers and to maintain them: each new release has an impact to the other driver, which may be difficult to track properly especially if drivers come from different furnishers.
Moreover, dependency between drivers may even be forbidden with some operating system, e.g., Linux for instance.
The second solution depicted in FIG. 2b comprises only one software driver: the audio driver AD able to handle both types of output apparatuses, LS, VB. The vibrator service VS should then directly interwork with it. As it sits in all interactions between the services (vibrator service VS, but also audio service, not depicted), it can control the access and properly handle the concurrent accesses to a same hardware resource, LS, VB.
However, such a design requires the vibrator service VS to be adapted to interwork with the audio driver AD. It has thus impact in the user space and the solution needs to maintain a proprietary module inside this user space. It further prevents integrating easily a third party application, based on the vibrator driver.
Such a solution is therefore not desirable.